home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Cream of the Crop 20
/
Cream of the Crop 20 (Terry Blount) (1996).iso
/
utility
/
ccache11.zip
/
EQANDA.TXT
< prev
next >
Wrap
Text File
|
1996-06-22
|
21KB
|
532 lines
EQANDA COPYRIGHT 1995-1996 horio shoichi EQANDA
NAME
eqanda.txt - Expected Questions And Answers
CONTENTS
This section contains the questions probably raised in using
concache.exe and the family programs, the DOS disk cache
program, and their answers. Following is the contents of
this section.
Why And How Cache Programs Speed Up Disk Io ?
What Are The Elements To Limit Concurrency ?
How Much Memory Should Be Prepared For Cache ?
How Concache.exe Can Be Tuned, In Terms Of Conven-
tional Memory ?
Is There Anything To Note With Relation To Serial Com-
munications Software ?
Troubleshooting
QUESTION
Why And How Cache Programs Speed Up Disk Io ?
ANSWER
Actually, disk cache programs don't speed up disk io.
Instead, they reduce the number of disk io operations. They
work to the user program as if disk io is completed as soon
as possible. They buffer disk data in a large memory area
called disk cache buffer (hereafter simply termed cache).
For read requests, if the data to be read reside in the
cache, data is supplied from cache. Also, data to be read
next by user programs are read and stored in the cache. This
method of speed up is called "read ahead" or "preread". For
write requests, the data to be written is copied into the
cache and user programs "think" the data to be written are
really written to disks. The data are actually written at
the cache program's convenience. This method of speeding up
the write requests is called "delay write", "write behind",
"write after", or "postwrite".
First generation of PC cache programs were generally reluc-
tant to use postwrite. This is thought of as a too special
luxury. Data to be written are written to disks as soon as
requested. The method to handle writes this way is called
"write-through".
When cache programs arrived on the market which use post-
write, it is found the programs more than double the speed
of writes. This is because disk allocation table, known as
FAT, is located at the top of disk and data space at the
Concache 1.10 Last Update: 19 June 1996 1
EQANDA COPYRIGHT 1995-1996 horio shoichi EQANDA
opposite corner, every write request first writes FAT mark-
ing as used and then turns head to the allocated area and
write data sectors. Postwrite in effect eliminates repeated
writes on FAT by submitting to DOS yet unwritten FAT. So,
not only actual number of write operations are reduced but
most head movements are eliminated by not needing to actu-
ally go back and forth to FAT area.
When working on floppy, you might have experienced severe
performance degradation if buffers= statement in config.sys
file is inadequately written. Also you might have observed
writes get slow down as your program proceed. What cache
programs do, up to this generation, is to extend the con-
fig.sys statement buffers= to a large cache buffer.
Next come so called "advanced" cache programs which attempt
to write data back concurrently with user programs. These
cache programs don't wait keyboard idle time, for example,
to write back cached data. This means traditional DOS pro-
grams' common inception that because disk writes are slow
they must be held into application program's buffers until
absolute needs arise to write them back is wrong. Writing
data as required is in fact faster and, perhaps less impor-
tant, eliminates the need of huge buffers from each applica-
tion program. In addition, because data are written as they
are produced, there are less chances of accidental data
loss. They become faster, safer and leaner.
It might be possible to think disk speed up has taken place
beginning with this generation.
Concache.exe belongs to this generation, and has added
another generality. It allows concurrency as far as there is
no reason to refrain from. The result is one floppy, one
BIOS disk, and as many as SCSI disks configurable into DOS
can be driven concurrently with DOS/user programs.
QUESTION
What Are The Elements To Limit Concurrency ?
ANSWER
From hardware point of view, floppies can not perform io
concurrently each other due to floppy controller design.
Also, IDE disks cannot. SCSI disks can perform io in paral-
lel, as seen on many multiprogramming operating systems. At
this level, one floppy, one IDE disk and SCSI disks can
operate concurrently.
Concache 1.10 Last Update: 19 June 1996 2
EQANDA COPYRIGHT 1995-1996 horio shoichi EQANDA
The next level to consider is BIOS to support io operations.
As far as published BIOS listing is concerned, there is no
reason floppy and IDE disk cannot operate concurrently.
SCSI drivers are usually written to do io asynchronously.
Here comes BIOS capability to distinguish disk events. Stan-
dard BIOS handle only two "type"s of disks, which is suffi-
cient for floppies and IDE disk environments, as found in
most PC configurations. Fortunately, ASPI (advanced SCSI
programming interface) specification, now broadly employed,
supports a mechanism effectively similar to BIOS disk event
notification, called command posting. (See appropriate man-
ual about this.) This allows handle individual disk's
events.
At this level no situations about concurrency issue is
changed.
The next level of the factor is device driver's non-
reentrancy. Even if a device driver manages several disks,
it expects its requests come serially but not while the pre-
vious requests are in progress. In fact, most known device
drivers lose reentrancy necessary for concurrency at the
very first two steps of driver code execution.
Also, io.sys handles int13, which is passed through by
almost any disk device call, in non-reentrant way. So, you
may think if third party device driver is used, for example
using io.sys for floppies and that for the other disk
devices, then at least the combination of one floppy and one
hard disk should work concurrently. But no. If both share
int13, then they don't work concurrently.
Next comes the DOS drive letter availability. If, for exam-
ple, a SCSI disk is split into two partitions, with many
good reasons, the user loses one drive letter for one disk.
These two partitions cannot share the io operation time.
Those constitute inherent limitations of concurrency. In
practice, there are resource limitations for programs under
DOS. For example ASPI drivers may limit the number of pack-
ets that it can accept at once.
Likewise, ccdisk.exe can limit the concurrency of SCSI disks
from its command line.
Finally, concache.exe can limit concurrency in two ways.
1) concurrency= option limits the number of concurrent
devices.
Concache 1.10 Last Update: 19 June 1996 3
EQANDA COPYRIGHT 1995-1996 horio shoichi EQANDA
2) io_buffers= option specifies insufficient io buffers to
let devices work concurrently.
QUESTION
How Much Memory Should Be Prepared For Cache ?
ANSWER
There are certainly optimal points of cache size. Unfortu-
nately, the points are too dependent on application and the
mix. There is no clear way to estimate